\documentclass[10pt,a4paper]{article}
\usepackage[utf8x]{inputenc}
\usepackage{ucs}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}

\author{BENSIALI Salim & SID-LAKHDAR Mohamed}
\title{Rapport Projet Objets Dupliqués}

\begin{document}
\maketitle
\newpage
\tableofcontents
\newpage

\section{Introduction}


\subsection{Partage de ressources}

\subsection{Duplication et Invalidation}


\section{Conception}


\subsection{Analyse}

\subsubsection{Problème général}
La mission d'un système de partage de donnée est de rendre des donnée diponnible pour plusieurs client en même temps, et de leurs donnés la possiblilité d'acceder à ces données en lecture ou en écriture.  Le système doit cepandant assurer certaine propriétés.  La plus critique de ces propriétés est la \textbf{cohérence} des données.  La seconde propriété est la rapidité du système à assurer le service de partage.  La cohérence ne doit cepandant jamais être sacrifiée en faveur de la rapidité du service qui dépend fortement des spécificités du problème, car selon le nombre d'ecriture par rapport aunombre de lecture, on choisira soit une stratégies dite \textit{write-back} ou une stratégies dite \textit{write-invalidate}.  Notre problème nous contraint à utiliser la seconde méthode.  Cela signifie que la solution que nous devons crée doit être optimiser pour le cas où il y a beaucoups de lectures et peut d'écritures.  En terme de rapidité de service, cela signifie que les accès en lecture aux données doivent être optimiser, et les accès en ecriture doivent prioritèrement respecté le critère de cohérence des données, et de faire au mieu en ce qui concerne la rapidité.

\subsubsection{Communication}

\subsubsection{Synchronisation}
La synchronisation est l'élément principale du système qui vas assurer la cohérence des données.  Le principe de la synchronisation est de sérialisé le paraléllisme d'un système en certains points.  Une sérialisation totale serai la façon la plus simple de répondre au critère de cohérence.  Le problème est qu'en détruisant le paralélisme, on réduit considérablement les performances du système.  Il faut donc trouver le meilleur équilibre possible entre paralélisme et sérialisation afin d'assurer en priorité la cohérence des données, et de rendre le système aussi rapide que possible dans son cadre d'application.

\subsubsection{Transparence}

\subsubsection{Références}
Le dernier service que notre système doit rendre est le partage d'objets complexes, i.e, le partage d'objets qui en référence d'autres.  Le problème apparent que ce serice soulève est la copie de ces objets.  Il s'agit de savoir s'il faut copier les objets référencés par le premier objet ou non.  Le cas échéant, un problème soujacent survient dans le cas où l'objet référencé à aussi une référence sur l'objet référançant.  D'autre problèmes tout aussi sérieux apparaissent.  Par exemple, une synchronisation d'un objet comlexe doit-elle induire une synchronisation des objets référencés? Auquel cas, comment éviter les problèmes de deadlock dans le cas d'objet référencés mutuèlement?

\subsection{Synthèse}

\subsubsection{Solution générale}
La solution que nous trouverons devra impérativement respecter l'interface client, soit le front-end.  Nous somme libre toutefois de modifier le back-end proposé par le sujet, du moment que la solution réponde à ses exigences.  Nous avons décider de garder l'architecture à n clients et 1 serveur proposé.  Une solution sans serveur a été envisagé mias semble être bien trôp compliquée à metre ne oeuvre, et demanderai beaucoup trop de temps.  Nous avons cepandant modifier l'interface du serveurs afin de l'adapté aux choix qui ont été fait.

\subsubsection{Communication}

\subsubsection{Synchronisation}
La solution de synchronisation que nous avons choisie concorde en certains points avec la solution proposée lors des séances de suivi de projet, mais en diffère en certains autres points.  Nous tâcherons d'expliqué dans cette section le fonctionnement de la solution choisie.  Nous la comparerons par la suite avec celle proposée en cours.
\paragraph*{}
Les principales classe qui entre en jeu dans ce projet sont les classe Client, Server, SharedObject et ServerObject.  Les principales acteurs de la synchronisation dans notre solution sont les classes SharedObject et Server.  La classe Client n'étant qu'un simple intermédiaire.
Afin de comprendre le mode de foctionnement de notre solution, il serait bon de considérer les classes ShareObject et Server comme des \textbf{Automates Finis Deterministes}.
\paragraph*{}
Une longue description de la méthode standard a été introduite dans le sujet.  Nous n'allons donc décrir que les spécificité de notre solution par rapport à la solution générale.  Dans le cas où une application demande un droit d'écriture sur un SharedObject, celui-çi vas envoyer une requête au serveur.  Ce dernier à alors deux possibilités : Une première possibilité serai de donner l'autorisation au SharedObject, après avoir accomplit certaine invalidation auprès des autres instances de SharedObject présente chez les autres client.  Cela signifie qu'à l'instant présent, personne d'autre ne demande le droit à l'écriture, et que le serveur n'à pas envoyer entre temps une requête à ce SharedObject pour lui enlever son droit de lecture, s'il l'a déjà.  Une seconde possibilité serai qu'il lui refuse l'accès en ecriture.  Ce cas est possible si quelqu'un d'autre à demander le droit à l'écriture avant lui ou, dans le cas particulier où le serveur requête en même temps ce SharedObject afin de le déstituer de son droit de lecture.  Cette seconde possiblité est notre solution au problème principale d'interblocage qui pourrait survenir.  Si cette seconde possibilité venait à arrivé, le SharedObject requéteur doit retenter sa chance autant de fois que cela s'avèrerea nécessaire afin d'obtenir son droit à l'ecriture.
\paragraph*{}
La différence majeur de philosophie entre notre solution et celle proposée en suivi de projet est que la notre relache la synchronisation au niveau du serveur, alors que l'autre relache la synchronisation au niveau du client.  Nous essayerons de voir par la suite les avantages et incovéniant des deux méthode.

\subsubsection{Transparence}

\subsubsection{Références}


\section{Codage}


\subsection{Communication}

\subsection{Synchronisation}
Le langage JAVA donne au developpeur une multitudes d'outils de synchronisation.  Ces outils vont du plus bas niveau tel les Mutex intégrés par defaut dans les objets JAVA, jusqu'aux structures de données thread-safe tel la classe Vector.
Nous avons dûe résoudres différents problèmes de synchronisation.  L'un des premiers fût l'allocation des identifants aux objets partagés.  L'outil JAVA le plus adapté à cette situation fût la classe \textbf{AtomicInteger}.  Cette classe permet de manipuler un entier de façon totalement synchrone.  La méthode \textit{getNextAndIncr()} nous a permis de résoudre ce problème en générant des identificateurs tous différents des précédent.  Cette méthode étant totalement thread-safe, on a la garantie que tout les identifiant que l'on génère sont belle et bien distinct.
Un autre problème fût celui de la synchronisation des accès au ressources.  Ce problème étant le principale frein dans le système, il nous a fallue utiliser des outils de synchronisation de bas niveau afin d'augmenter les performances.  Nous avons pour cela utiliser les \textbf{Mutex} et les \textbf{variables de conditions}.

\subsection{Introspection}

\subsection{Sérialization}


\section{Test}

\subsection{Fonctinnement}
Nous avons élaborer une stratégie afin de tester l'application.  Notre principale objectif est que chaque client puisse accéder aux données, et que l'application assure bien la cohérence des données.  Pour cela, nous avons lancer plusieurs application sur plusieurs client (une application par client).  Chaqu'une de ces application suit alors un scénario.  Pour que le test soit le plus générle possible, nous avons fait intervenir le \textbf{hasard}.  Le scénario de chaque application consiste à accéder aux données en lecture et en ecriture suivant des fréquences déterminées.
Après avoire lancer plusieurs tests, avec des fréquences divers et variées, on a observée que le résultat final était bien celui qu'il devai être.  Le service que l'on propose semble respecter la cohérence des données.

\subsection{Permormance}
En terme de performance, on a remarqué que les performances décroissent lorsque la fréquence des accès en écriture augumente.  Ce constat semble toutefois être logique.
On a remarqué aussi que plus on augmente le nombre de client, et plus l'accès en écriture à un client qui demande un accès en écriture et a qui cette accès a été préalablement refusée est difficile.  Celui-çi doit attendre une assez longue durée avant d'avoir accès aux données.

\subsection{Résultats}


\section{Conclusion}

\paragraph*{resume work}
En terme de conclusion, notre travail a consister à développer un service de partage de données suivant une stratégie \textit{write invalidate}.  Il permet l'accès et le partage des données qu'elle soit sur la même machine ou sur différente machines.  Il garantie la cohérence des données à l'entrée.  En terme de rapidité de service, il a été conçue et et développer de sorte à optimiser les accès en lecture, mais ne garantie cependant pas la rapidité pour l'accès en écriture.  En plus de ce service de base, on a ajouter certaines fonctionnalitées qui facilite la vie du développeurs en rendant certaines transparentes certaines opérations pénibles.  Enfin, ce service gère toutes sorte d'objets qu'il soit simples ou complexes.

\paragraph*{experience}
Ce projet est le premier projet que l'on a eu à faire qui emploie les mécanismes de synchronisation et de communication inter-application.  En tant que tel, nous avons pu nous confronter a de nombreuses problématiques que ce genre de technilogies induisent.  Mais l'expérience qu'il nous a permis d'aquérir vas au-delà de cela : Nous avons découvert l'exrème difficulté de la phase de \textbf{déboguage}. Cette phase n'a jamais eu autant d'envergure dans les autres projets que nous avons eu à traiter jusqu'a maintenant.  La problématique de la synchronisation n'a fait qu'augmenter la difficulté.  Nous avons découvers que cette phase nous oblige à réfléchir sur notre travail et de rentrer dans un profond niveau de détail.  Nous avons toujours penser que la meilleur façon de comprendre un projet est de le concevoir.  Ce projet nous a prouver que non.  La phase de débogage permet une meilleur compréhension encore.

\end{document}
